home *** CD-ROM | disk | FTP | other *** search
/ Danny Amor's Online Library / Danny Amor's Online Library - Volume 1.iso / html / rfc / rfcxxxx / rfc1556 < prev    next >
Text File  |  1995-07-25  |  6KB  |  171 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. Network Working Group                                      H. Nussbacher
  8. Request for Comments: 1556                      Israeli Inter-University
  9. Category: Informational                                  Computer Center
  10.                                                            December 1993
  11.  
  12.  
  13.                 Handling of Bi-directional Texts in MIME
  14.  
  15. Status of this Memo
  16.  
  17.    This memo provides information for the Internet community.  This memo
  18.    does not specify an Internet standard of any kind.  Distribution of
  19.    this memo is unlimited.
  20.  
  21. Abstract
  22.  
  23.    This document describes the format and syntax of the "direction"
  24.    keyword to be used with bi-directional texts in MIME.
  25.  
  26. Description
  27.  
  28.    The MIME standards (RFC 1521 and 1522) defined methods for
  29.    transporting non-ASCII data via a standard RFC822 e-mail system.
  30.    Specifically, the Content-type field allows for the inclusion of any
  31.    ISO language such as Arabic (ISO-8859-6) or Hebrew (ISO-8859-8).  The
  32.    problem is that the these two languages are read from right to left
  33.    and can have bi-directional data such as mixed Hebrew and English on
  34.    the same line.
  35.  
  36.    Fortunately, ECMA (European Computer Manufacturers Association) has
  37.    tackled this problem previously and has issued a technical report
  38.    called "Handling of Bi-Directional Texts".  ECMA TR/53, as it is
  39.    called, was used to update the Standard ECMA-48 which in turn was
  40.    used as the basis for ISO/IEC 6429 which was adopted under a special
  41.    "fast track procedure". It is based on this information that a new
  42.    character set is being defined which will indicate that the bi-
  43.    directional message is either encoded in implicit mode or explicit
  44.    mode.  The default is visual mode which requires no special character
  45.    set other than the standard ones previously defined by ISO-8859.
  46.  
  47.    Examples of new character sets for bi-directionality support:
  48.  
  49.             Content-type: text/plain; charset=ISO-8859-6-e
  50.             Content-type: text/plain; charset=ISO-8859-6-i
  51.             Content-type: text/plain; charset=ISO-8859-8-e
  52.             Content-type: text/plain; charset=ISO-8859-8-i
  53.  
  54.  
  55.  
  56.  
  57.  
  58. Nussbacher                                                      [Page 1]
  59.  
  60. RFC 1556                  Bi-directional Texts             December 1993
  61.  
  62.  
  63.    The "i" suffix refers to implicit mode and the "e" suffix refers to
  64.    explicit mode.
  65.  
  66. Implicit
  67.  
  68.    Implicit directionality is a presentation method in which the
  69.    direction is determined by an algorithm according to the type of
  70.    characters and their position relative to the adjacent characters and
  71.    according to their primary direction.   The complete algorithm is
  72.    quite complex and sites wishing to implement it should refer to the
  73.    ECMA Technical Report for further details.
  74.  
  75. Explicit
  76.  
  77.    Explicit directionality is a presentation method in which the
  78.    direction is explicitly defined by using control sequences which are
  79.    interleaved within the text and are used for direction determination.
  80.    This presentation method is also defined in ECMA TR/53, which defines
  81.    three new control functions and updates 22 existing control functions
  82.    in the ECMA-48 standard.
  83.  
  84. Visual
  85.  
  86.    Visual directionality is a presentation method that displays text
  87.    according to the primary display direction only, which is left to
  88.    right.  All text is viewed in the same direction which is the primary
  89.    display direction.  The displaying application is not aware of the
  90.    contents direction and displays the text as if it were a uni-
  91.    directional text.  The composing application needs to prepare the
  92.    text in such a way that it will be displayed correctly.  No control
  93.    characters or algorithms are used to determine how the data is to be
  94.    displayed. This is the simplest of all methods and the default method
  95.    for use with MIME encoded texts.
  96.  
  97. References
  98.  
  99.    [ECMA TR/53] Handling of Bi-Directional Texts, European Computer
  100.                 Manufacturers Association, 114 Rue du Rhone, CH-1204,
  101.                 Geneva, Switzerland, June 1992.
  102.  
  103.    [ISO-6429]   Information Technology - Control Functions for Coded
  104.                 Character Sets, 3rd edition, December 15, 1992.
  105.  
  106.    [ISO-8859]   Information Processing -- 8-bit Single-Byte Coded
  107.                 Graphic Character Sets, Part 6: Arabic alphabet, ISO
  108.                 8859-6, 1988.
  109.  
  110.  
  111.  
  112.  
  113.  
  114. Nussbacher                                                      [Page 2]
  115.  
  116. RFC 1556                  Bi-directional Texts             December 1993
  117.  
  118.  
  119.    [ISO-8859]   Information Processing -- 8-bit Single-Byte Coded
  120.                 Graphic Character Sets, Part 8: Latin/Hebrew alphabet,
  121.                 ISO 8859-8, 1988.
  122.  
  123.    [RFC822]     Crocker, D., "Standard for the Format of ARPA Internet
  124.                 Text Messages", STD 11, RFC 822, UDEL, August 1982.
  125.  
  126.    [RFC1521]    Borenstein N., and N. Freed, "MIME (Multipurpose
  127.                 Internet Mail Extensions) Part One: Mechanisms for
  128.                 Specifying and Describing the Format of Internet
  129.                 Message Bodies", Bellcore, Innosoft, September 1993.
  130.  
  131.    [RFC1522]    Moore K., "MIME Part Two: Message Header Extensions for
  132.                 Non-ASCII Text", University of Tennessee,
  133.                 September 1993.
  134.  
  135. Security Considerations
  136.  
  137.    Security issues are not discussed in this memo.
  138.  
  139. Author's Address
  140.  
  141.    Hank Nussbacher
  142.    Computer Center
  143.    Tel Aviv University
  144.    Ramat Aviv
  145.    Israel
  146.  
  147.    Fax: +972 3 6409118
  148.    Phone: +972 3 6408309
  149.    EMail: hank@vm.tau.ac.il
  150.  
  151.  
  152.  
  153.  
  154.  
  155.  
  156.  
  157.  
  158.  
  159.  
  160.  
  161.  
  162.  
  163.  
  164.  
  165.  
  166.  
  167.  
  168.  
  169.  
  170. Nussbacher                                                      [Page 3]
  171.